Some electronic devices are designed to operate according to entitlements given to these devices. For example settop boxes for receiving and in particular decrypting an encrypted data stream representing a pay TV channel need to have means for decrypting the stream. These entitlements may also allow or disallow certain uses of the content of the stream, such as recording or export. The control for this entitlement is often processed by a general purpose CPU.
Mostly electronic devices of this kind incorporate integrated circuits, which integrate all or nearly all components of a computer or an electronic system into one single integrated circuit, so called system on chip (SOC). Accordingly the functions of said electronic devices are represented by the comprised SOCs.
In many cases the SOCs in an electronic device are not application specific, hence their function is defined by the software provided to the SOCs. In order to control the content to be processed according to the entitlements the corresponding software or data must be transferred to the SOCs or digital processing system (DPS). In the following description the term Digital Processing System abbreviated as DPS is used.
To further simplify the wording in the following description the term data may mean executable code, i.e. program code executable in a processor, as well as non-executable binary data, which is to be processed in a processor using a piece of executable program code already present in the processor. Non-executable data for example may be configuration data, which for example may enable or disable functions in the DPS or which may set or unset properties in the DPS or which may be any other information used by the DPS.
Software can be easily copied and distributed among devices without any loss in quality. Accordingly a data stream stored on a storage media can be multiplied and easily distributed, thereby producing copies of the streamed data. However manufacturers or providers of special services, like pay TV providers for example, need a method to ensure that only authorized software can be executed on DPSs, such that the software will correctly enforce the entitlements for processing a received data stream.
One method to ensure that authorized software only is executed by the processor of a DPS is to include a security system that checks for a signature, i.e. a digital signature, of the code or data before it is processed in the processor of the DPS.
A digital signature of data is used to provide authentication of said data. In a conventional digital signature scheme, for example known from a public key infrastructure PKI, a pair of keys, i.e. a private key and a public key, is used to generate and check digital signatures. The digital signature is produced by a signing algorithm on input of the data and a signing key, i.e. the private key. The signing algorithm for example applies a hash function to compute a unique signature from the data and the private key. The digital signature, which is also digital information, may be sent to a recipient together with the data. As the public key of the key pair is publicly available, the recipient may use it. The signature of the data can be verified or checked at the recipient's end by a signature verifying algorithm, that on input of the data and a verifying key, i.e. the public key of the key pair, outputs either that the signature is valid or invalid. If the signature is valid then the signature has been computed using the private key associated with the used public key. That is, when ownership of the private key is bound to a specific user or authority, then a valid signature shows that the data was sent by that user or authority. Furthermore the valid signature ensures that the data have not been amended after the signature was computed.
So by checking a signature associated with the data in question the recipient can check, i.e. authenticate, that the data was sent by the owner of the private key and is the original data. However the recipient must have the public key of the sender and furthermore must be sure that the used key actually is that of the sender.
Data, which for example may be the executable program code, in this way may be signed by an authority. The authority approves by its signature that the data or code has been authorized. That is the authority has approved that the data may be processed in the DPS, i.e. the executable code may be executed in a processor or non-executable data may be processed in a processor using a program running on the processor.
When the data in question is transferred to the DPS the security system in the DPS checks for a signature of the data before the data is processed in the DPS. That is the security system in the DPS uses the public key of the authority to check the validity of the signature. The public key used for checking the signature is stored in the memory of the DPS. In order to prevent fraud attempts on the public key, which a user of a settop box may try for example by replacing a key by his own public key thus making himself an authorizing authority, the public key may be hard coded in the DPS, for example by using one time programmable memory, which cannot be changed once written, or by Read Only Memory, set at manufacturing time. So any data provided to the DPS for execution or processing is checked for a valid signature, wherein the public key ensures that the signature was calculated using the secret key corresponding to the hard coded public key. Accordingly only the owner of the pair of public and secret key is capable of calculating a signature and is thus capable of authorizing software or data to be executed or processed by a DPS.
This system assumes, that each data to be processed in the DPS is signed by the signing authority. Accordingly when a new or updated piece of executable code or configuration data is to be processed by the DPS, then the signing authority has to calculate the signature, which must be transferred to the DPS in order to allow the processing in the DPS. This may cause the signing authority to sign data, of which it does not have real knowledge. For example when the signing authority is a pay TV provider, who authorizes the execution of decryption software in a DPS for decrypting a pay TV channel. As usually the pay TV provider will not produce the settop boxes for decrypting the channel, but a third party will produce the settop boxes and the software executed therein. Whenever software in the settop box is to be updated the provider has to authorize the updated software before transferring the updated release to a settop box. The pay TV provider usually will trust the producer of the settop box and accordingly will sign the updated data. There may be other situations, in which a signing authority actually will not have real knowledge about the data to be transferred to the settop box. So there may be situations, where the signing authority will have to trust the producer of the data and thus simply sign data items to allow the settop box, i.e. the SOC within the settop box, to process the data, because due to the amount and complexity of this data it is practically impossible to examine the data thoroughly.
Consequently a more flexible method for authorizing and authenticating software and data before execution or processing is desirable. For example such that a manufacturer of a DPS can sign its own data items, wherein the manufacturer is restricted to sign data items depending on the particular system, the security provider.